<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow-IPC: ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe Struct Reference</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow-IPC<span id="projectnumber">&#160;1.0.2</span>
   </div>
   <div id="projectbrief">Flow-IPC project: Full implementation reference.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div id="nav-path" class="navpath">
  <ul>
<li class="navelem"><a class="el" href="namespaceipc.html">ipc</a></li><li class="navelem"><a class="el" href="namespaceipc_1_1transport.html">transport</a></li><li class="navelem"><a class="el" href="namespaceipc_1_1transport_1_1struc.html">struc</a></li><li class="navelem"><a class="el" href="namespaceipc_1_1transport_1_1struc_1_1sync__io.html">sync_io</a></li><li class="navelem"><a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">Channel</a></li><li class="navelem"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html">Msg_in_pipe</a></li>  </ul>
</div>
</div><!-- top -->
<div class="header">
  <div class="summary">
<a href="#pub-types">Public Types</a> &#124;
<a href="#pub-attribs">Public Attributes</a> &#124;
<a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe-members.html">List of all members</a>  </div>
  <div class="headertitle"><div class="title">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe Struct Reference</div></div>
</div><!--header-->
<div class="contents">

<p>Data and policy with respect to receipt of the next/currently-incomplete in-message.  
 <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#details">More...</a></p>
<div class="dynheader">
Collaboration diagram for ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe:</div>
<div class="dyncontent">
<div class="center"><iframe scrolling="no" frameborder="0" src="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe__coll__graph.svg" width="843" height="314"><p><b>This browser is not able to show SVG: try Firefox, Chrome, Safari, or Opera instead.</b></p></iframe>
</div>
<center><span class="legend">[<a href="graph_legend.html">legend</a>]</span></center></div>
<table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="pub-types" name="pub-types"></a>
Public Types</h2></td></tr>
<tr class="memitem:af253db32507ef0191eef0fc926a65f54"><td class="memItemLeft" align="right" valign="top">enum &#160;</td><td class="memItemRight" valign="bottom">{ <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54a2909901e853fa702041678e01f37f7de">S_RCV_WITH_OR_SANS_HNDL_DEMUX</a>
, <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54ae237f1213d4bbf83cf354afb87238ecf">S_RCV_WITH_HNDL_ELSE_ERROR</a>
, <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54af9cda4dc28baebac6ea0b91401fefeaa">S_RCV_SANS_HNDL_ONLY</a>
 }</td></tr>
<tr class="memdesc:af253db32507ef0191eef0fc926a65f54"><td class="mdescLeft">&#160;</td><td class="mdescRight">The immutable mode of behavior along this pipe, which must be enabled: Whether to use <a class="el" href="classipc_1_1transport_1_1Native__handle__receiver.html#ae4ac1685f00467a6516f9f24f5d8a280" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Native_h...">Native_handle_receiver::async_receive_native_handle()</a> or <a class="el" href="classipc_1_1transport_1_1Blob__receiver.html#a8bc6642dbf4b5e3fdee9f3442f2bbe84" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Blob_sen...">Blob_receiver::async_receive_blob()</a>; and what to accept/do on receipt.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54">More...</a><br /></td></tr>
<tr class="separator:af253db32507ef0191eef0fc926a65f54"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table><table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="pub-attribs" name="pub-attribs"></a>
Public Attributes</h2></td></tr>
<tr class="memitem:a3d239c5a1e29bd6db1ee7c4764616549"><td class="memItemLeft" align="right" valign="top">enum ipc::transport::struc::sync_io::Channel::Msg_in_pipe:: { ... } &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a3d239c5a1e29bd6db1ee7c4764616549">m_lead_msg_mode</a></td></tr>
<tr class="memdesc:a3d239c5a1e29bd6db1ee7c4764616549"><td class="mdescLeft">&#160;</td><td class="mdescRight">The immutable mode of behavior along this pipe, which must be enabled: Whether to use <a class="el" href="classipc_1_1transport_1_1Native__handle__receiver.html#ae4ac1685f00467a6516f9f24f5d8a280" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Native_h...">Native_handle_receiver::async_receive_native_handle()</a> or <a class="el" href="classipc_1_1transport_1_1Blob__receiver.html#a8bc6642dbf4b5e3fdee9f3442f2bbe84" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Blob_sen...">Blob_receiver::async_receive_blob()</a>; and what to accept/do on receipt.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a3d239c5a1e29bd6db1ee7c4764616549">More...</a><br /></td></tr>
<tr class="separator:a3d239c5a1e29bd6db1ee7c4764616549"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a1b6834c271148af382c46ef948d1faab"><td class="memItemLeft" align="right" valign="top">size_t&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a1b6834c271148af382c46ef948d1faab">m_n_segs_left_after_this_read</a></td></tr>
<tr class="memdesc:a1b6834c271148af382c46ef948d1faab"><td class="mdescLeft">&#160;</td><td class="mdescRight">During an async-read (note: given <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a> and until channel is hosed, there is <em>always</em> an async-read happening): the number of segments needed <em>after</em> the currently-async-awaited next segment does arrive to complete the message.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a1b6834c271148af382c46ef948d1faab">More...</a><br /></td></tr>
<tr class="separator:a1b6834c271148af382c46ef948d1faab"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:af73c6fcead6a866df1524e01b5654222"><td class="memItemLeft" align="right" valign="top">flow::util::Blob *&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222">m_target_blob</a></td></tr>
<tr class="memdesc:af73c6fcead6a866df1524e01b5654222"><td class="mdescLeft">&#160;</td><td class="mdescRight">Target buffer for the <code>async_receive_*()</code> operation in-progress.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222">More...</a><br /></td></tr>
<tr class="separator:af73c6fcead6a866df1524e01b5654222"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:ad27cbaa9b01823f31fb2ae47835974df"><td class="memItemLeft" align="right" valign="top"><a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8">Native_handle</a>&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#ad27cbaa9b01823f31fb2ae47835974df">m_target_hndl</a></td></tr>
<tr class="memdesc:ad27cbaa9b01823f31fb2ae47835974df"><td class="mdescLeft">&#160;</td><td class="mdescRight">Target <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> for the <code>async_receive_native_handle()</code> operation in-progress or last-completed; null if the last or in-progress operation is <code>async_receive_blob()</code>.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#ad27cbaa9b01823f31fb2ae47835974df">More...</a><br /></td></tr>
<tr class="separator:ad27cbaa9b01823f31fb2ae47835974df"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:aa02a4835e4bd31cd5f6ea9bbd37eeff4"><td class="memItemLeft" align="right" valign="top"><a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a84287334d14f54c97f7dbb0d5b04cca5">Msg_in_ptr_uniq</a>&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4">m_incomplete_msg</a></td></tr>
<tr class="memdesc:aa02a4835e4bd31cd5f6ea9bbd37eeff4"><td class="mdescLeft">&#160;</td><td class="mdescRight">Target (incomplete) in-message for the <code>async_receive_*()</code> operation in-progress; one is always in-progress once <code><a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a></code> has been called, until the pipe is hosed.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4">More...</a><br /></td></tr>
<tr class="separator:aa02a4835e4bd31cd5f6ea9bbd37eeff4"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a56c1f9cdcfd2a145114ab080199eb704"><td class="memItemLeft" align="right" valign="top">flow::util::Blob *&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a56c1f9cdcfd2a145114ab080199eb704">m_proto_neg_blob</a></td></tr>
<tr class="memdesc:a56c1f9cdcfd2a145114ab080199eb704"><td class="mdescLeft">&#160;</td><td class="mdescRight">Used only for the first in-message in the pipe, before any <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a>, when doing protocol negotiation: this is analogous to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222" title="Target buffer for the async_receive_*() operation in-progress.">m_target_blob</a> but for the simple/small <code>ProtocolNegotiation</code> capnp-<code>struct</code>.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a56c1f9cdcfd2a145114ab080199eb704">More...</a><br /></td></tr>
<tr class="separator:a56c1f9cdcfd2a145114ab080199eb704"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a83b9a3a7ddee7b6bfe14724bfccfc6ba"><td class="memItemLeft" align="right" valign="top"><a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8">Native_handle</a>&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a83b9a3a7ddee7b6bfe14724bfccfc6ba">m_proto_neg_hndl</a></td></tr>
<tr class="memdesc:a83b9a3a7ddee7b6bfe14724bfccfc6ba"><td class="mdescLeft">&#160;</td><td class="mdescRight">Used only for the first in-message in the pipe, before any <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a>, when doing protocol negotiation: this is analogous to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#ad27cbaa9b01823f31fb2ae47835974df" title="Target Native_handle for the async_receive_native_handle() operation in-progress or last-completed; n...">m_target_hndl</a>.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a83b9a3a7ddee7b6bfe14724bfccfc6ba">More...</a><br /></td></tr>
<tr class="separator:a83b9a3a7ddee7b6bfe14724bfccfc6ba"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a58b72930ddbf7e45936f8c8f34105324"><td class="memItemLeft" align="right" valign="top">boost::movelib::unique_ptr&lt; <a class="el" href="classipc_1_1transport_1_1struc_1_1Heap__reader.html">Heap_reader</a> &gt;&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a58b72930ddbf7e45936f8c8f34105324">m_proto_neg_reader_in</a></td></tr>
<tr class="memdesc:a58b72930ddbf7e45936f8c8f34105324"><td class="mdescLeft">&#160;</td><td class="mdescRight">Used only for the first in-message in the pipe, before any <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a>, when doing protocol negotiation: this is analogous to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a> but for the simple/small <code>ProtocolNegotiation</code> capnp-<code>struct</code>.  <a href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a58b72930ddbf7e45936f8c8f34105324">More...</a><br /></td></tr>
<tr class="separator:a58b72930ddbf7e45936f8c8f34105324"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table>
<a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2>
<div class="textblock"><div class="compoundTemplParams">template&lt;typename Channel_obj, typename Message_body, typename Struct_builder_config, typename Struct_reader_config&gt;<br />
struct ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe</div><p >Data and policy with respect to receipt of the next/currently-incomplete in-message. </p>
<p >Depending on whether 1 or 2 in-pipes are enabled in <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a4abac89dbd4d26c79b7915990f751a76" title="See Async_io_obj counterpart.">Owned_channel</a>, and in the former case what kind of in-pipe it is (see <a class="el" href="classipc_1_1transport_1_1Channel.html#aafb0767df5f1dfb535c9467ce717f93f" title="Useful for generic programming: true if and only if types imply at least the blobs pipe is enabled.">Channel::S_HAS_BLOB_PIPE</a>, <a class="el" href="classipc_1_1transport_1_1Channel.html#ab6decf2691a2cab6c3b5187bad1e368b" title="Useful for generic programming: true if and only if types imply at least the handles pipe is enabled.">Channel::S_HAS_NATIVE_HANDLE_PIPE</a>, and similar), there may be 1 or 2 of these objects (sets of policy + state) in <code>*this</code>. See <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a9c04f15d4d17cd43aca70136119e1d28" title="1 or 2 active (via optional) structs containing policy and state w/r/t receipt of low-level (unstruct...">m_rcv_pipes</a> (<code>std::optional</code> being used to permanently disable up to 1 of them) of this type.</p>
<h3>Algorithm/background</h3>
<p ><a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a4abac89dbd4d26c79b7915990f751a76" title="See Async_io_obj counterpart.">Owned_channel</a>, potentially being a <a class="el" href="classipc_1_1transport_1_1Native__handle__receiver.html" title="A documentation-only concept defining the behavior of an object capable of reliably/in-order receivin...">Native_handle_receiver</a>, is possibly capable of receiving unstructured messages, each message bearing a blob and, optionally, a <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a>. Suppose the opposing peer wants to send a structured message M, plus <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> S. The latter can just be sent in a single message. The former (M) is serialized into 1 or 2+ RAM blobs (a/k/a segments in capnp parlance), depending on its size. This shall <em>always</em> be 1 if we are SHM-backed.</p>
<p >Then: the whole structured message M + <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> S shall be sent as:</p><ul>
<li>1 <em>lead</em> message containing mandatory metadata (containing notably the message ID); <em>and</em> S;</li>
<li>1 <em>continuation</em> message containing the 1st segment serializing M itself;</li>
<li>0+ further <em>continuation</em> messages serializing the rest of M. (Usually 0; always 0 if SHM-backed.)</li>
</ul>
<p >There are also internal messages &ndash; presumed rare. These are represented by the 1st bullet point only: there are no continuation messages at all. The algorithm here operates, therefore, under the assumption that each structured message = 1 lead message; plus 0+ continuation messages. However in perf analysis one should assume 1 continuation message, as most messages are user messages, and those usually are serializable as 1 continuation message each.</p>
<p >If M = just a lead message (internal-message case): then it is simply sent in one unstructured message, received in a single async_receive_native_handle() call. In this case <code>m_incomplete_msg</code> is created just before that async-read, completed fully just upon completing that async-read, and constructed/assigned again (and then the next async-read is executed). S is S, and the internal-message is deserialized from the 1 segment. (As of this writing there never is an S paired with an internal message; but to future-proof this let's assume it is possible.)</p>
<p >Otherwise (user-message case): the sender shall send:</p><ol type="1">
<li><em>Lead</em> message (containing amother other things how many continuation messages are coming next; and S);</li>
<li>1+ <em>continuation</em> message(s), the first containing the first segment (blob); the rest (if any) containing the rest of them. S is never paired with a continuation message.</li>
</ol>
<p ><code>m_incomplete_msg</code> shall store that state across the 2+ async-reads, up until the last of the N segments has been received (then it is constructed/assigned again, and then the next async-read is executed). As with the lead-message-only case, just before being replaced with a new one, <code>m_incomplete_msg</code> is fed into the next layer within <code>*this</code>, where the structured message is fed to the user, etc.</p>
<p >Which pipe is used for these 2+ messages?</p><ul>
<li>If <a class="el" href="classipc_1_1transport_1_1Channel.html#a634da813ea03c07d8360a738eca002c4" title="Useful for generic programming: true if and only if types imply only the blobs pipe is enabled.">Channel::S_HAS_BLOB_PIPE_ONLY</a> is <code>true</code>, it is a fatal error. No <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> can be transmitted.</li>
<li>If <a class="el" href="classipc_1_1transport_1_1Channel.html#a717bffc2086ccf834bc7a1137c1127eb" title="Useful for generic programming: true if and only if types imply only the handles pipe is enabled.">Channel::S_HAS_NATIVE_HANDLE_PIPE_ONLY</a> is <code>true</code>, then naturally the handles pipe is used (<a class="el" href="classipc_1_1transport_1_1Channel.html#a288e61b4e19b9621f4f978fab88bcab0" title="Yields hndl_rcv()-&gt; same method.">Channel::async_receive_native_handle()</a>) &ndash; it's the only pipe available at any rate.</li>
<li>If <a class="el" href="classipc_1_1transport_1_1Channel.html#a85184d886cee9b4a0d0e7b67796a238b" title="Useful for generic programming: true if and only if types imply both blobs and handles pipes are enab...">Channel::S_HAS_2_PIPES</a> is <code>true</code>, then:<ul>
<li>The lead message is expected over the handles pipe (<a class="el" href="classipc_1_1transport_1_1Channel.html#a288e61b4e19b9621f4f978fab88bcab0" title="Yields hndl_rcv()-&gt; same method.">Channel::async_receive_native_handle()</a>), as it's the only pipe capable of transporting S.</li>
<li>(Attn: subtlety!) The continuation messages are <em>also</em> expected over that pipe, even though the blobs pipe <em>is</em> capable of transporting these. Why? Answer: At this stage we're not dealing with the structured layer yet (pre-deserialization which isn't yet possible), so there are no sequence numbers. It would require absurd contraptions to distinguish a non-handle-bearing continuation message with a handle-bearing lead message from a non-handle-bearing lead message; to resolve races between the 2 parallel in-pipes; etc. More on this around the to-do below.</li>
</ul>
</li>
</ul>
<p >Now assume no <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> S wants to be sent with M. The serialization logic is all the same &ndash; there's just no S transmitted along with the lead message. The transport media are different; as any pipe can transmit these unstructured messages, not needing to transmit these strange native handle thingies. So then which pipe is used for these messages?</p><ul>
<li>If <a class="el" href="classipc_1_1transport_1_1Channel.html#a634da813ea03c07d8360a738eca002c4" title="Useful for generic programming: true if and only if types imply only the blobs pipe is enabled.">Channel::S_HAS_BLOB_PIPE_ONLY</a> is <code>true</code>, then naturally the blobs pipe is used &ndash; being the only 1 avail.</li>
<li>If <a class="el" href="classipc_1_1transport_1_1Channel.html#a717bffc2086ccf834bc7a1137c1127eb" title="Useful for generic programming: true if and only if types imply only the handles pipe is enabled.">Channel::S_HAS_NATIVE_HANDLE_PIPE_ONLY</a> is <code>true</code>, then the handles pipe is used &ndash; being the only 1 avail (and perfectly capable of transmitting just-blobs).</li>
<li>If <a class="el" href="classipc_1_1transport_1_1Channel.html#a85184d886cee9b4a0d0e7b67796a238b" title="Useful for generic programming: true if and only if types imply both blobs and handles pipes are enab...">Channel::S_HAS_2_PIPES</a> is <code>true</code>, then: Although either pipe <em>could</em> be used, we use the blobs pipe; the idea being that the only reason to configure both pipes in a <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html" title="sync_io-pattern counterpart to async-I/O-pattern transport::struc::Channel.">Channel</a> is for performance (certainly it doesn't make anything <em>simpler</em> after all), and since the handles-pipe alone was deemed insufficient, we'll reserve it for handle-bearing structured user messages only.<ul>
<li>Perf caveat: Isn't it "giving away" perf to (for the sake of simplicity) send messages pertaining to sans-handle lead messages along the handles pipe (and not the blobs pipe)? Well, yes, at least a bit. In practice every user message has a lead message &ndash; the metadata-bearing one (with message ID, originating-message-if-any ID, etc.), and at least 1 continuation message (the actual user message &ndash; plus, if the message is so big it can't fit into 1 segment, then more message(s) to carry the serialization). (Let's assume usually there's only 1 continuation message: if too-big messages are common, much more impact-heavy perf measures are necessary anyway &ndash; namely using SHM-aware serialization which will <em>never</em> transmit bulk data. Those measures are available and encouraged!) So typically, if the user message is indeed handle-bearing, we'll send the metadata pre-message along the handles pipe (with a handle) immediately followed by the user payload (without handle). The user continuation message could indeed have been sent over the blobs pipe, so we are giving away a bit of perf with every message. I (ygoldfel) simply did not deem this giveaway worth the complexity in the reassembly logic needed to compensate for this. It could be something to look at when/if a perf deficit is identified, or we're doing a hardcore optimization pass at this code. (That said &ndash; this only applies to handle-bearing user messages in the first place. Further, again, we are talking about the low-level perf of copying small amounts of data after already being backed by SHM to essentially eliminate bulk copying. Intuitively this should be minor in the big picture.) Here's the to-do:</li>
</ul>
</li>
</ul>
<dl class="todo"><dt><b><a class="el" href="todo.html#_todo000030">Todo:</a></b></dt><dd>Look into the algorithm documented in <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Channel::Msg_in_pipe</a> wherein (with 2 pipes in the channel) some low-level messages associated with handle-bearing user structured messages are sent over the (presumably somewhat slower) handles pipe despite, themselves, not containing a native handle being transmitted. See text just above this to-do in the code.</dd></dl>
<p >That describes what happens for each structured message M, paired with <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> S &ndash; or not paired with it. So the question is how to make these possibilities work together. Answer:</p>
<p >To get this to work, depending entirely on <code>Channel::S_HAS_*</code>, there are 1 or 2 <code><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Msg_in_pipe</a></code>s: <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a9c04f15d4d17cd43aca70136119e1d28" title="1 or 2 active (via optional) structs containing policy and state w/r/t receipt of low-level (unstruct...">m_rcv_pipes</a>, each one's <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a3d239c5a1e29bd6db1ee7c4764616549" title="The immutable mode of behavior along this pipe, which must be enabled: Whether to use Native_handle_r...">Msg_in_pipe::m_lead_msg_mode</a> (which is <code>const</code>!) determining (1) which <code>async_receive_*()</code> API will be called; and (2) how the async non-error result will be handled. (See <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a> where this is kicked off for the first time, meaning each of the 2 <code><a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Msg_in_pipe</a></code>s is cted, setting <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a3d239c5a1e29bd6db1ee7c4764616549" title="The immutable mode of behavior along this pipe, which must be enabled: Whether to use Native_handle_r...">m_lead_msg_mode</a> forever.)</p><ul>
<li>For a given <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Msg_in_pipe</a>: when no incomplete message is in-progress (such as the start of <code>*this</code>): create empty structured <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#ac3da0ac1306b63c9e38c47b8c31e3cd2" title="See Async_io_obj counterpart.">Msg_in</a> (assign to <code>m_incomplete_msg</code>), do the appropriate <code>m_channel.async_receive_*()</code>; then when it async-yields result store the first segment blob in it (and native handle if any). If no more segments are expected for this structured message, done (<code>*m_incomplete_msg</code> can be fed to the next layer). Repeat this bullet point (create new <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#ac3da0ac1306b63c9e38c47b8c31e3cd2" title="See Async_io_obj counterpart.">Msg_in</a>, async-read, etc.). Otherwise:</li>
<li><code>m_incomplete_msg</code> stays (it is still incomplete). <code>m_channel.async_receive_blob()</code> (meaning expect an unstructured continuation in-message, and if it somehow includes a <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a>, then it's a low-level <code><a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html" title="sync_io-pattern counterpart to async-I/O-pattern transport::struc::Channel.">Channel</a></code>-hosing error). When it async-yields result, add it to the structured message <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#ac3da0ac1306b63c9e38c47b8c31e3cd2" title="See Async_io_obj counterpart.">Msg_in</a> <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a>. Repeat this bullet point until it is completed, at which point done &ndash; <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a> can be fed to the next layer; back to the preceding bullet point (create new <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#ac3da0ac1306b63c9e38c47b8c31e3cd2" title="See Async_io_obj counterpart.">Msg_in</a>, async-read, etc.).</li>
</ul>
<p >If <code>Owned_channel::S_HAS_2_PIPES</code>, then 2 <code>async_receive_*()</code>s are possible simultaneously, and there are indeed 2x <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Msg_in_pipe</a> in <code>*this</code>; one for just blobs (<a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54af9cda4dc28baebac6ea0b91401fefeaa" title="Use Blob_receiver::async_receive_blob(); accept sans-handle message only; with-handle message means f...">Msg_in_pipe::S_RCV_SANS_HNDL_ONLY</a>), one for just blob-and-handle combos (<a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54ae237f1213d4bbf83cf354afb87238ecf" title="Use Native_handle_receiver::async_receive_native_handle(); accept with-handle message only; sans-hand...">Msg_in_pipe::S_RCV_WITH_HNDL_ELSE_ERROR</a>). They can be interleaved. Otherwise there's only 1 <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Msg_in_pipe</a>, namely:</p><ul>
<li>If the 1 pipe is blobs-only, <code>Owned_channel::S_HAS_BLOB_PIPE_ONLY</code>: it's, obviously, for just blobs (<a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54af9cda4dc28baebac6ea0b91401fefeaa" title="Use Blob_receiver::async_receive_blob(); accept sans-handle message only; with-handle message means f...">Msg_in_pipe::S_RCV_SANS_HNDL_ONLY</a>).</li>
<li>If the 1 pipe is blobs-and-handles, <code>Owned_channel::S_HAS_NATIVE_HANDLE_PIPE_ONLY</code>: it's for both types of messages (<a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af253db32507ef0191eef0fc926a65f54a2909901e853fa702041678e01f37f7de" title="Use Native_handle_receiver::async_receive_native_handle(); accept with-handle and sans-handle lead in...">Msg_in_pipe::S_RCV_WITH_OR_SANS_HNDL_DEMUX</a>). </li>
</ul>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01275">1275</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>
</div><h2 class="groupheader">Member Enumeration Documentation</h2>
<a id="af253db32507ef0191eef0fc926a65f54" name="af253db32507ef0191eef0fc926a65f54"></a>
<h2 class="memtitle"><span class="permalink"><a href="#af253db32507ef0191eef0fc926a65f54">&#9670;&nbsp;</a></span>anonymous enum</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">anonymous enum</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>The immutable mode of behavior along this pipe, which must be enabled: Whether to use <a class="el" href="classipc_1_1transport_1_1Native__handle__receiver.html#ae4ac1685f00467a6516f9f24f5d8a280" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Native_h...">Native_handle_receiver::async_receive_native_handle()</a> or <a class="el" href="classipc_1_1transport_1_1Blob__receiver.html#a8bc6642dbf4b5e3fdee9f3442f2bbe84" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Blob_sen...">Blob_receiver::async_receive_blob()</a>; and what to accept/do on receipt. </p>
<p >See <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a> for background discussion to clarify this nicely. </p>
<table class="fieldtable">
<tr><th colspan="2">Enumerator</th></tr><tr><td class="fieldname"><a id="af253db32507ef0191eef0fc926a65f54a2909901e853fa702041678e01f37f7de" name="af253db32507ef0191eef0fc926a65f54a2909901e853fa702041678e01f37f7de"></a>S_RCV_WITH_OR_SANS_HNDL_DEMUX&#160;</td><td class="fielddoc"><p >Use <a class="el" href="classipc_1_1transport_1_1Native__handle__receiver.html#ae4ac1685f00467a6516f9f24f5d8a280" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Native_h...">Native_handle_receiver::async_receive_native_handle()</a>; accept with-handle and sans-handle lead in-message; then demultiplex into the slightly different async code path 1 or 2 depending on which occurred. </p>
<p >(However, any continuation message along either code path must be sans-handle.) </p>
</td></tr>
<tr><td class="fieldname"><a id="af253db32507ef0191eef0fc926a65f54ae237f1213d4bbf83cf354afb87238ecf" name="af253db32507ef0191eef0fc926a65f54ae237f1213d4bbf83cf354afb87238ecf"></a>S_RCV_WITH_HNDL_ELSE_ERROR&#160;</td><td class="fielddoc"><p >Use <a class="el" href="classipc_1_1transport_1_1Native__handle__receiver.html#ae4ac1685f00467a6516f9f24f5d8a280" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Native_h...">Native_handle_receiver::async_receive_native_handle()</a>; accept with-handle message only; sans-handle message means fatally hosed <code>*this</code>. </p>
<p >(However, any continuation message must be sans-handle.)</p>
<dl class="section note"><dt>Note</dt><dd>For context: If this is in use, then another <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Msg_in_pipe</a> must be in <code>S_RCV_SANS_HNDL_ONLY</code> <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a3d239c5a1e29bd6db1ee7c4764616549" title="The immutable mode of behavior along this pipe, which must be enabled: Whether to use Native_handle_r...">m_lead_msg_mode</a> also (in <code>*this</code>). </dd></dl>
</td></tr>
<tr><td class="fieldname"><a id="af253db32507ef0191eef0fc926a65f54af9cda4dc28baebac6ea0b91401fefeaa" name="af253db32507ef0191eef0fc926a65f54af9cda4dc28baebac6ea0b91401fefeaa"></a>S_RCV_SANS_HNDL_ONLY&#160;</td><td class="fielddoc"><p >Use <a class="el" href="classipc_1_1transport_1_1Blob__receiver.html#a8bc6642dbf4b5e3fdee9f3442f2bbe84" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Blob_sen...">Blob_receiver::async_receive_blob()</a>; accept sans-handle message only; with-handle message means fatally hosed <code>*this</code> automatically at the lower level (inside <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html" title="sync_io-pattern counterpart to async-I/O-pattern transport::struc::Channel.">Channel</a>). </p>
<p >(Any continuation message must be sans-handle as well.)</p>
<dl class="section note"><dt>Note</dt><dd>For context: If this is in use, then another <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html" title="Data and policy with respect to receipt of the next/currently-incomplete in-message.">Msg_in_pipe</a> <em>might</em> be in <code>S_RCV_SANS_HNDL_ONLY</code> <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#a3d239c5a1e29bd6db1ee7c4764616549" title="The immutable mode of behavior along this pipe, which must be enabled: Whether to use Native_handle_r...">m_lead_msg_mode</a> also (in <code>*this</code>). It also might <em>not</em> exist; namely if <a class="el" href="classipc_1_1transport_1_1Channel.html#a634da813ea03c07d8360a738eca002c4" title="Useful for generic programming: true if and only if types imply only the blobs pipe is enabled.">Channel::S_HAS_BLOB_PIPE_ONLY</a>. Then, simply, <code>*this</code> can never receive native handles (which is an entirely possible use). </dd></dl>
</td></tr>
</table>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01286">1286</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

</div>
</div>
<h2 class="groupheader">Member Data Documentation</h2>
<a id="aa02a4835e4bd31cd5f6ea9bbd37eeff4" name="aa02a4835e4bd31cd5f6ea9bbd37eeff4"></a>
<h2 class="memtitle"><span class="permalink"><a href="#aa02a4835e4bd31cd5f6ea9bbd37eeff4">&#9670;&nbsp;</a></span>m_incomplete_msg</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname"><a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a84287334d14f54c97f7dbb0d5b04cca5">Msg_in_ptr_uniq</a> <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_incomplete_msg</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Target (incomplete) in-message for the <code>async_receive_*()</code> operation in-progress; one is always in-progress once <code><a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a></code> has been called, until the pipe is hosed. </p>
<p >It's used as follows:</p><ul>
<li>When the async-read for the lead unstructured in-message is about to be called, this is constructed, and its <code>add_serialization_segment()</code> returns a <code>Blob*</code> to the next blob (inside <code>*m_incomplete_msg</code>) to async-read-into. That <code>Blob*</code> is saved to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222" title="Target buffer for the async_receive_*() operation in-progress.">m_target_blob</a>, and the async-read begins.</li>
<li>Once it is complete, <code>*m_target_blob</code> is <code>resize()</code>d to account for the actual segment size.<ul>
<li>If the message consists of only 1 segment, done. Emit completed structured in-message to the next layer; and go back to step 1 (get next lead message). Else must get first continuation message:</li>
</ul>
</li>
<li>Call <code>add_serialization_segment()</code> again; save the returned <code>Blob*</code> into <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222" title="Target buffer for the async_receive_*() operation in-progress.">m_target_blob</a> again; begin async-read again.</li>
<li>Once it is complete, <code>*m_target_blob</code> is <code>resize()</code>d again to account for the actual seg-size again.<ul>
<li>If that's the last segment, done. Emit completed structured in-message to the next layer; and go back to step 1 (get next lead message). Go back to step 1 (get the next lead message). Else must get next continuation message: Go to step 3 again.</li>
</ul>
</li>
</ul>
<p >Subtlety: It's a <code>unique_ptr</code> (not <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#acde2b3866547a30958035203d9d89928" title="See Async_io_obj counterpart.">Msg_in_ptr</a> <code>shared_ptr</code>) for anti-leak safety/perf. It is moved and thus upgraded to a <code>shared_ptr</code> (<a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#acde2b3866547a30958035203d9d89928" title="See Async_io_obj counterpart.">Msg_in_ptr</a>) when message completed. </p>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01381">1381</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03056">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_continuation_msg()</a>, and <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02912">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_lead_msg()</a>.</p>

</div>
</div>
<a id="a3d239c5a1e29bd6db1ee7c4764616549" name="a3d239c5a1e29bd6db1ee7c4764616549"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a3d239c5a1e29bd6db1ee7c4764616549">&#9670;&nbsp;</a></span></h2>

<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">enum  { ... }  <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_lead_msg_mode</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>The immutable mode of behavior along this pipe, which must be enabled: Whether to use <a class="el" href="classipc_1_1transport_1_1Native__handle__receiver.html#ae4ac1685f00467a6516f9f24f5d8a280" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Native_h...">Native_handle_receiver::async_receive_native_handle()</a> or <a class="el" href="classipc_1_1transport_1_1Blob__receiver.html#a8bc6642dbf4b5e3fdee9f3442f2bbe84" title="In PEER state: Asynchronously awaits one discrete message – as sent by the opposing peer via Blob_sen...">Blob_receiver::async_receive_blob()</a>; and what to accept/do on receipt. </p>
<p >See <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a> for background discussion to clarify this nicely. </p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02732">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_async_read_lead_or_continuation_msg()</a>, <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03163">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_async_read_proto_neg_msg()</a>, <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03056">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_continuation_msg()</a>, and <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02912">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_lead_msg()</a>.</p>

</div>
</div>
<a id="a1b6834c271148af382c46ef948d1faab" name="a1b6834c271148af382c46ef948d1faab"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a1b6834c271148af382c46ef948d1faab">&#9670;&nbsp;</a></span>m_n_segs_left_after_this_read</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">size_t <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_n_segs_left_after_this_read</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>During an async-read (note: given <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a> and until channel is hosed, there is <em>always</em> an async-read happening): the number of segments needed <em>after</em> the currently-async-awaited next segment does arrive to complete the message. </p>
<p >When the lead in-message is being async-read, this shall be set to 0. (If that lead in-message indicates the total # of <em>further</em> segments to expect is 0, then the 0 is "correct"; if the # is 1+, then this member is "corrected" to equal that #. Before each continuation async-read it is decremented by 1, including ahead of the first continuation async-read. So if original seg-count is 1, then this is 0 ahead of lead read, 0 ahead of continuation read. If it's 2, then this is 0 ahead of lead read, 1 ahead of continuation read one, 0 ahead of continuation read two. And so on.) </p>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01327">1327</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02732">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_async_read_lead_or_continuation_msg()</a>, <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03056">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_continuation_msg()</a>, and <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02912">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_lead_msg()</a>.</p>

</div>
</div>
<a id="a56c1f9cdcfd2a145114ab080199eb704" name="a56c1f9cdcfd2a145114ab080199eb704"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a56c1f9cdcfd2a145114ab080199eb704">&#9670;&nbsp;</a></span>m_proto_neg_blob</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">flow::util::Blob* <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_proto_neg_blob</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Used only for the first in-message in the pipe, before any <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a>, when doing protocol negotiation: this is analogous to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222" title="Target buffer for the async_receive_*() operation in-progress.">m_target_blob</a> but for the simple/small <code>ProtocolNegotiation</code> capnp-<code>struct</code>. </p>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01387">1387</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03163">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_async_read_proto_neg_msg()</a>, and <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03236">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_proto_neg_msg()</a>.</p>

</div>
</div>
<a id="a83b9a3a7ddee7b6bfe14724bfccfc6ba" name="a83b9a3a7ddee7b6bfe14724bfccfc6ba"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a83b9a3a7ddee7b6bfe14724bfccfc6ba">&#9670;&nbsp;</a></span>m_proto_neg_hndl</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname"><a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8">Native_handle</a> <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_proto_neg_hndl</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Used only for the first in-message in the pipe, before any <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a>, when doing protocol negotiation: this is analogous to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#ad27cbaa9b01823f31fb2ae47835974df" title="Target Native_handle for the async_receive_native_handle() operation in-progress or last-completed; n...">m_target_hndl</a>. </p>
<p >However such protocol-negotiation messages shall never include any non-null <code>Native_handle</code>; but we still need a place to put it for the <code>.async_receive_native_handle()</code> API. </p>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01394">1394</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03163">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_async_read_proto_neg_msg()</a>, and <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03236">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_proto_neg_msg()</a>.</p>

</div>
</div>
<a id="a58b72930ddbf7e45936f8c8f34105324" name="a58b72930ddbf7e45936f8c8f34105324"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a58b72930ddbf7e45936f8c8f34105324">&#9670;&nbsp;</a></span>m_proto_neg_reader_in</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">boost::movelib::unique_ptr&lt;<a class="el" href="classipc_1_1transport_1_1struc_1_1Heap__reader.html">Heap_reader</a>&gt; <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_proto_neg_reader_in</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Used only for the first in-message in the pipe, before any <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a>, when doing protocol negotiation: this is analogous to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a> but for the simple/small <code>ProtocolNegotiation</code> capnp-<code>struct</code>. </p>
<p >It is simpler though: we expect 1 segment, always heap-based, and don't need the <code><a class="el" href="classipc_1_1transport_1_1struc_1_1Msg__in.html" title="A structured in-message instance suitable as received and emittable (to user) by struc::Channel.">Msg_in</a></code> niceties; so we use a <code><a class="el" href="classipc_1_1transport_1_1struc_1_1Heap__reader.html" title="Implements Struct_reader concept by straightforwardly interpreting a serialization by Heap_fixed_buil...">Heap_reader</a></code> directly. This is <code>.reset()</code> after protocol-negotiation completes to save some RAM. </p>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01402">1402</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03236">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_proto_neg_msg()</a>.</p>

</div>
</div>
<a id="af73c6fcead6a866df1524e01b5654222" name="af73c6fcead6a866df1524e01b5654222"></a>
<h2 class="memtitle"><span class="permalink"><a href="#af73c6fcead6a866df1524e01b5654222">&#9670;&nbsp;</a></span>m_target_blob</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">flow::util::Blob* <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_target_blob</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Target buffer for the <code>async_receive_*()</code> operation in-progress. </p>
<p >(Note: given <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#a0c00bab2dad604dde176c4190553915c" title="Permanently memorizes the incoming-direction on-error handler, thus authorizing the emission of any i...">start_and_poll()</a> and until channel is hosed, there is <em>always</em> an async-read in-progress.) <code>m_target_blob.capacity()</code> is always a positive constant, the max length accepted along the underlying <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html" title="sync_io-pattern counterpart to async-I/O-pattern transport::struc::Channel.">Channel</a> in-pipe. <code>m_target_blob-&gt;capacity() == m_target_blob-&gt;size()</code>, and the async-receive was passed <code>m_target_blob-&gt;mutable_buffer()</code> with that <code>.size()</code>. If it is completed, then <code>m_target_blob-&gt;size()</code> is "corrected" to the # of bytes (successfully) received in the unstructured message &ndash; and <code>m_target_blob</code> is immediately re-assigned to point to the <em>next</em> `Blob.</p>
<p >To be clear: <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222" title="Target buffer for the async_receive_*() operation in-progress.">m_target_blob</a> points to a <code>Blob</code> inside <code>*m_incomplete_msg</code>. The <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#ac3da0ac1306b63c9e38c47b8c31e3cd2" title="See Async_io_obj counterpart.">Msg_in</a> is in charge of supplying memory area to read-to; depending on the deserialization engine it might be obtaining that memory from the regular heap, or some pool, or....</p>
<p >So when <code>m_target_blob-&gt;size()</code> is "corrected," the correction is as required by the <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html#ac3da0ac1306b63c9e38c47b8c31e3cd2" title="See Async_io_obj counterpart.">Msg_in</a> contract for <a class="el" href="classipc_1_1transport_1_1struc_1_1Msg__in.html#a3a1a75d7d7b108d46efa1892dd2571b7" title="Prior to deserialization_*() obtains a memory area max_sz bytes long into which the user may write-to...">Msg_in::add_serialization_segment()</a>. That way it knows the actual size of the segment within the serialization, as opposed to the max size of such a segment. </p>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01346">1346</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02732">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_async_read_lead_or_continuation_msg()</a>, <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03056">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_continuation_msg()</a>, and <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02912">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_lead_msg()</a>.</p>

</div>
</div>
<a id="ad27cbaa9b01823f31fb2ae47835974df" name="ad27cbaa9b01823f31fb2ae47835974df"></a>
<h2 class="memtitle"><span class="permalink"><a href="#ad27cbaa9b01823f31fb2ae47835974df">&#9670;&nbsp;</a></span>m_target_hndl</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Channel_obj , typename Message_body , typename Struct_builder_config , typename Struct_reader_config &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname"><a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8">Native_handle</a> <a class="el" href="classipc_1_1transport_1_1struc_1_1sync__io_1_1Channel.html">ipc::transport::struc::sync_io::Channel</a>&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::Msg_in_pipe::m_target_hndl</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Target <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> for the <code>async_receive_native_handle()</code> operation in-progress or last-completed; null if the last or in-progress operation is <code>async_receive_blob()</code>. </p>
<p >Therefore, regardless of which async-receive just completed, one can view pair (<a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222" title="Target buffer for the async_receive_*() operation in-progress.">m_target_blob</a>, <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#ad27cbaa9b01823f31fb2ae47835974df" title="Target Native_handle for the async_receive_native_handle() operation in-progress or last-completed; n...">m_target_hndl</a>) as its result (it shall be null if and only if the received message is sans-handle &ndash; in any context).</p>
<p >Analogously to <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#af73c6fcead6a866df1524e01b5654222" title="Target buffer for the async_receive_*() operation in-progress.">m_target_blob</a>, this member is reinitialized immediately upon successful async-read; if it is non-null, then it is moved-into <a class="el" href="structipc_1_1transport_1_1struc_1_1sync__io_1_1Channel_1_1Msg__in__pipe.html#aa02a4835e4bd31cd5f6ea9bbd37eeff4" title="Target (incomplete) in-message for the async_receive_*() operation in-progress; one is always in-prog...">m_incomplete_msg</a> (and thus nullified); if it is null, then... it remains null (a <code>.null()</code> <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> moved-to another <a class="el" href="namespaceipc_1_1transport.html#a7ee4551983d9df16ec16a3139bac50e8" title="Convenience alias for the commonly used type util::Native_handle.">Native_handle</a> simply remains <code>.null()</code>). </p>

<p class="definition">Definition at line <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l01359">1359</a> of file <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a>.</p>

<p class="reference">Referenced by <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02732">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_async_read_lead_or_continuation_msg()</a>, <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l03056">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_continuation_msg()</a>, and <a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html#l02912">ipc::transport::struc::sync_io::Channel&lt; Channel_obj, Message_body, Struct_builder_config, Struct_reader_config &gt;::rcv_on_async_read_lead_msg()</a>.</p>

</div>
</div>
<hr/>The documentation for this struct was generated from the following file:<ul>
<li>transport/struc/sync_io/<a class="el" href="ipc__transport__structured_2src_2ipc_2transport_2struc_2sync__io_2channel_8hpp_source.html">channel.hpp</a></li>
</ul>
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Thu May 2 2024 23:56:39 for Flow-IPC by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
